@dlaehnemann The PRs will be squashed into one commit to the main branch anyway. If you think this should stay as multiple pieces, you'd have to do separate PRs or we'd have to somehow to the merge manually.

Also, I'm not sure about the classification as "fix". It might be a "feat!" (new feature with breaking change requiring major version bump). Thoughts?

Basically, this has grown in scope since Johannes approved the original PR. and I did the overhaul of the linting test suite, which has been merged. So I cherry-picked all the relevant stuff here, so that we would have a clean diff in the pull request, mainly for the review of this pull request.
Without the cherry-picking, the resolution of the merge conflicts would have been harder and I also messed up the rebase, because I forgot that I was working on a fork...

But this is not yet done. I'm still working through all the cases with the new outputs: policy and trying to get the linting right (including dedicated test cases).

OK, I think this is good to be reviewed and possibly merged.

This is another step towards proper linting of recipes with multiple outputs, also working towards supporting the new recipe.yaml format in that regard:
https://rattler-build.prefix.dev/v0.65.0/reference/multi_output/

However, I have restricted it to linting the stuff that the existing multi-output recipes in bioconda require. This means that the linting currently does not check all of the inheritance behavior of the v1 recipe format.
For example, the build number is only checked (and possibly fixed) on the top-level of the recipe, not per-output, as all the existing recipes just have a single build number and especially updating the automatic fixing code for the build numbers would be more involved.
Also, it might make sense to eventually adopt the lint (and build) infrastructure of conda-forge at some point, which is already implementing the new recipe format in a backwards compatible manner. So duplicating all that work over here might be a waste of time...

Finally, the failing ty qc check on the typing seems unrelated:

error[unresolved-attribute]: Attribute `keys` is not defined on `bool` in union `dict[Any, Any] | bool`
   --> bioconda_utils/circleci.py:262:48
    |
262 |             f"success={x['success']} {':'.join(x['urls'].keys())}" for x in self.parsed
    |                                                ^^^^^^^^^^^^^^
    |

Found 1 diagnostic

And I don't understand why the urls entry in self.parsed should possibly be bool instead of a dict, and where this implicit typing would happen. The respective code filling that key should always return a dict, even if it is empty because there's no match (and never a bool):

            urls = {
                key: url for url, key in re.findall(r"<(http[^|>]+)\|([^>]+)>", text)
            }

@bioconda/core , anybody up for a review?

OK, I think this is good to be reviewed and possibly merged.

This is another step towards proper linting of recipes with multiple outputs, also working towards supporting the new recipe.yaml format in that regard: https://rattler-build.prefix.dev/v0.65.0/reference/multi_output/

However, I have restricted it to linting the stuff that the existing multi-output recipes in bioconda require. This means that the linting currently does not check all of the inheritance behavior of the v1 recipe format. For example, the build number is only checked (and possibly fixed) on the top-level of the recipe, not per-output, as all the existing recipes just have a single build number and especially updating the automatic fixing code for the build numbers would be more involved. Also, it might make sense to eventually adopt the lint (and build) infrastructure of conda-forge at some point, which is already implementing the new recipe format in a backwards compatible manner. So duplicating all that work over here might be a waste of time...

Finally, the failing ty qc check on the typing seems unrelated:

error[unresolved-attribute]: Attribute `keys` is not defined on `bool` in union `dict[Any, Any] | bool`
   --> bioconda_utils/circleci.py:262:48
    |
262 |             f"success={x['success']} {':'.join(x['urls'].keys())}" for x in self.parsed
    |                                                ^^^^^^^^^^^^^^
    |

Found 1 diagnostic

And I don't understand why the urls entry in self.parsed should possibly be bool instead of a dict, and where this implicit typing would happen. The respective code filling that key should always return a dict, even if it is empty because there's no match (and never a bool):

            urls = {
                key: url for url, key in re.findall(r"<(http[^|>]+)\|([^>]+)>", text)
            }

@bioconda/core , anybody up for a review?

ty is not smart enough here, but the code is also quite old-fashioned I would say. Here is a PR that fixes this issue by using a dataclass instead: #1114